1. Field of the Invention
This invention relates in general to synchronizing two data storage systems during replication, and in particular to reconciling transactions stored in a replication system with transactions already performed on a target database.
2. Description of the Related Art
Replication is often defined as creating and managing two or more versions of some or all of a database. For example, in replication, creation and management often include copying some or all of a source database to one or more target databases, as well as synchronizing the source database with the target databases such that changes made to one are made to the others. Although replication includes a wide number of complexities, replication provides the advantage of, for example, geographically remote users having local copies of a database where each database is updated as if each user were working on a single, centralized database. Such distribution may also allow for load balancing for performance issues related to one or more computer systems or hardware. In addition, replication provides the ability to create mirrors of some or all of a database such that one of the mirrors may be accessed during failure or maintenance. Replication may also provide broadcast or consolidation functions, such as, for example, allowing local copies to synchronize with central copies of a database, or vice versa.
Based on the foregoing, system administrators employ replication in environments where substantially continuous data availability is desired. For example, on-line content providers, on-line retailers, or the like, often desire applications to be available to users substantially every day virtually all of the time. In such applications, many companies feel that downtime for system maintenance or failure recovery equates to business lost because of unavailability, untrustworthiness, or the like.
However, with today's complex and varying computer systems and hardware, substantially constantly available databases under replication are likely to incur at least some unsynchronizing events. For example, one of the source or target databases may need to undergo structural alterations or have an upgrade to the underlying database management system (DBMS). One of the foregoing databases may incur a catastrophic or other failure, or they may be in need of routine maintenance. Regardless of the cause, once an unsynchronizing event occurs, generally the still-available database becomes the source database providing continued access to users or applications, while the unsynchronized database becomes a target database for resynchronization.
Although several solutions exist for resynchronizing the target database with the source database, each carries a variety of drawbacks. For example, some solutions severely limit or entirely discontinue user access to the source database in order to resynchronize the target database. In such systems, a static copy of the source database is generally created, and the source and target databases are then brought back on-line at the same time. The clear drawback of the foregoing static-copy solution is that the source database is substantially unavailable to users or applications during the static copy. As mentioned in the foregoing, such unavailability may lead to counterproductive business consequences.
Another solution for resynchronizing the target database with the source database includes using the backup function of the underlying DBMS. For example, DBMSs, such as those commercially available from Oracle Corporation, often provide a hot backup feature allowing the target database to be recovered to a point in time just before the entire backup process ends. Although the hot backup solution provides an attractive mechanism for recreating the target database, the hot backup solution fails to account for restarting or continuing replication between the source and target databases.